1) Field of the Invention
The present invention relates to a service assignment apparatus. In particular, the present invention relates to a service assignment apparatus which assigns an appropriate service to one of a plurality of network elements constituting a network and having various functions, when the network element cannot provide a service corresponding to a service request, so that the corresponding service can be guaranteed in the entire network.
2) Description of the Related Art
Recently, various services are provided by a network, and some service are provided by processing a service request from an external device. However, networks often include a network element which cannot process a specific service request, and cannot therefore provide a corresponding service even though the network element has a service providing function. Nevertheless, it is not realistic to adapt all network elements constituting a network for such a specific service, and it is desirable to effectively use limited network resources.
The quality of service (QoS) control for guaranteeing a bandwidth and the class of service (CoS) control for prioritizing traffic are known as service controls provided by a specific network element.
The QoS control dynamically guarantees end-to-end service quality so as to prevent interruption or delay of image data or voice data, for example, in a video conference. The Resource Reservation Protocol (RSVP) is a protocol which is standardized by the IETF (Internet Engineering Task Force) for realizing the QoS control and dynamically guaranteeing a bandwidth. On the other hand, the CoS control for prioritizing traffic is a static service provided in accordance with a predetermined priority.
Operations in the case where network elements respectively providing different services exist between opposite ends are explained below.
FIGS. 19(A), 19(B), and 19(C) are diagrams illustrating operations of conventional network elements in exemplary cases where a service requester attempts to receive a bandwidth reservation service by using the RSVP protocol. FIG. 19(A) exhibits the first stage, FIG. 19(B) exhibits the second stage, and FIG. 19(C) exhibits the third stage. In FIGS. 19(A), 19(B), and 19(C), it is assumed that the sender 101 and the receiver 102 are a server and a client in a client-server system, respectively. The receiver 102 is connected to the sender 101 through a communication path established in a network, and an RSVP-compatible router 103, an RSVP-incompatible router 104 which is not yet compatible with RSVP, and an RSVP-compatible router 105 are located on the communication path. In this example, the service provided by the network constituted by the RSVP-compatible router 103, the RSVP-incompatible router 104, and the RSVP-compatible router 105 is reservation of a bandwidth.
In the first stage illustrated in FIG. 19(A), a path-designation message (Path message) is transmitted from the sender 101 to the receiver 102. The path-designation message is transferred through the RSVP-compatible router 103, the RSVP-incompatible router 104, and the RSVP-compatible router 105 to the receiver 102. When the path-designation message is transferred through each of the RSVP-compatible routers 103 and 105, each of the RSVP-compatible routers 103 and 105 stores path information.
Next, in the second stage illustrated in FIG. 19(B), in order to request a bandwidth reservation, the receiver 102 sends a bandwidth-reservation request message (Resv message) through the path to the sender 101. Each of the RSVP-compatible routers 103 and 105 makes a self-decision in response to the bandwidth-reservation request, and performs processing for the bandwidth reservation. Since the RSVP-incompatible router 104 cannot perform processing for bandwidth reservation, the RSVP-incompatible router 104 does not process the bandwidth-reservation request, and merely transfers the bandwidth-reservation request message to the next RSVP-compatible router 103.
In the third stage illustrated in FIG. 19(C), the sender 101 transmits data to the receiver 102. Since the bandwidth is reserved by the RSVP-compatible routers 103 and 105, the RSVP-compatible routers 103 and 105 can guarantee the bandwidth. However, the bandwidth is not reserved by the RSVP-incompatible router 104. Therefore, a problem can occur in the data transmitted from the sender 101 to the receiver 102. For example, a portion of the data may be lost before the receiver 102 receives the data.
As described above, when a network element which cannot process a service request exists on a communication path, the network element cannot recognize the service request, i.e., the network element ignores the service request. Therefore, the network element cannot provide the requested service. Resultantly, sometimes the network cannot provide the requested service.
FIGS. 20(A), 20(B), and 20(C) are diagrams illustrating operations of other conventional network elements. FIG. 20(A) exhibits the first stage, FIG. 20(B) exhibits the second stage, and FIG. 20(C) exhibits the third stage. In this example, each router does not make a self-decision as to whether or not the router should reserve a bandwidth in response to the bandwidth-reservation request, and instead a policy server 106 makes a decision as to whether or not each router should reserve a bandwidth for the bandwidth-reservation request, where the policy server 106 is provided for performing policy control operations in the network. In this example, the service provided by the network constituted by the RSVP-compatible router 103, the RSVP-incompatible router 104, and the RSVP-compatible router 105 is also bandwidth reservation.
In the first stage illustrated in FIG. 20(A), a path-designation message (Path message) is transmitted from the sender 101 to the receiver 102. The path-designation message is transferred through the RSVP-compatible router 103, the RSVP-incompatible router 104, and the RSVP-compatible router 105 to the receiver 102. When the path-designation message is transferred through each of the RSVP-compatible routers 103 and 105, each of the RSVP-compatible routers 103 and 105 stores path information.
Next, in the second stage illustrated in FIG. 20(B), in order to request a bandwidth reservation, the receiver 102 sends a bandwidth-reservation request message through the path to the sender 101. When each of the RSVP-compatible routers 103 and 105 receives the bandwidth-reservation request, the RSVP-compatible router requests permission for a bandwidth reservation from the policy server 106 in accordance with the Common Open Policy Service (COPS) protocol, which is a protocol proposed in the RSVP admission policy work group (RAP-WG) in the IETF, and used for performing admission control operations (which determines permission for or rejection of a reservation), where the admission control is performed during a bandwidth reservation process, for example, in accordance with RSVP.
The policy server 106 makes a decision as to whether to permit the bandwidth reservation or not, based on a policy which the policy server 106 has, and returns a decision result to the RSVP-compatible router 103 or 105 which requests the permission for a reservation. When each of the RSVP-compatible routers 103 and 105 is permitted to reserve the bandwidth, each of the RSVP-compatible routers 103 and 105 makes a reservation of the bandwidth. However, the RSVP-incompatible router 104 cannot perform processing for reserving a bandwidth. Therefore, the RSVP-incompatible router 104 does not process the bandwidth-reservation request, and merely transfers the bandwidth-reservation request message to the next RSVP-compatible router 103.
In the third stage illustrated in FIG. 20(C), the sender 101 transmits data to the receiver 102. Since the bandwidth is reserved by the RSVP-compatible routers 103 and 105, the RSVP-compatible routers 103 and 105 can guarantee the bandwidth. However, the bandwidth is not reserved by the RSVP-incompatible router 104. Therefore, even when the policy server 106 is provided in the network, the policy server 106 only makes a decision as to whether to permit the bandwidth reservation or not, and the policy server 106 does nothing for the RSVP-incompatible router 104. That is, the network cannot provide a bandwidth reservation service for the communication path from the sender 101 to the receiver 102.